How to Estimate Business Process Mapping for Software Projects
Jun/15/2020 Filed in: Process Mapping
There is no industry standard or common formula for estimating the work of business process mapping and modeling. That’s primarily because of the wide range of variables involved in the work. Secondarily, few organizations have any experience in performing or managing the work of business process mapping and modeling.
The most effective method of estimating is based on measuring your history of performing and managing the work. In other words, your first few process mapping/modeling projects will be hard to estimate. You’ll have to gain some carefully-measured experience so you can identify the extent and stability of the variables. With experience you’ll start to realize what those variables are and the extent of each variable.
I’ve been doing this kind of work for more than 20 years. Over that time, I’ve only seen one mathematically oriented estimating method. But that didn’t include any information about the effectiveness of the method. All the rest of the literature on the subject generally addresses the time consumed during so-called business process “discovery” meetings. These meetings are often labeled as group interviews, brainstorming, or Joint Application Development (JAD) session meetings. And it’s implied that these types of meetings are all that’s needed to effectively and efficiently gather, clarify, and confirm enough information to quickly create useful workflow diagrams.
Mapping vs Modeling
By the way, most organizations I’m aware of don’t make a distinction between business process mapping and business process modeling. To them, the terms are synonymous and both only refer to the work of creating business process workflow diagrams. Even within the community of business process mapping/modeling practitioners, there is little agreement about the definitions. Thus, one of the first factors to deal with is to define the difference between mapping and modeling.
In my vocabulary, business process mapping refers to the work of creating business process workflow diagrams. No other documentation is included in the scope of work. The work of business process modeling extends the documentation beyond workflow diagrams. While high-quality, detailed workflow diagrams can illustrate and communicate a lot of process information, other types of diagrams and documents provide additional, needed information and perspectives. Those needs and perspectives are determined by both the purpose of business process documentation and the audience and beneficiaries of the information. Bottom line, there is more work involved in process modeling than there is in process mapping.
Three Primary Variables
Since workflow diagramming exists in both process mapping and process modeling, we’ll start with the first three primary factors/variables related to the work. Those factors are (1.) the scope of processes to document, (2.) the level of detail required, (3.) the workflow diagramming notation to be used.
Primary Variable #1: The Scope of Processes to Document
A valuable tool and information to use in defining the scope of process mapping/modeling is APQC’s Process Classification Framework (PCF). As the name implies, a PCF is a categorized, multi-level outline of business processes commonly found in nearly every type of business enterprise. Using 13 different, high-level process classes it shows up to five sub-process levels for each.
For example, let’s say your project involves process modeling in support of the slection, configuration, and implementation of a new Applicant Tracking System (ATS) for the human resources department. Using the PCF as a guideline, ATS processes fall under the PCF’s “7.2 Recruit, source, and select employees” sub-process. That sub-process is a second-level process of the higher level, “7.0 Develop and Manage Human Capital,” process which is one of the 13 high-level processes of the PCF.
There are five separate sub-processes under “7.2 Recruit, source, and select employees”:
Each of those have between three and seven sub-processes under them. Specifically, in total, there are 23 distinct sub-process that could potentially be modeled. You have to admit, when you first saw the “7.2 Recruit, source, and select employees” high-level process name you probably weren’t thinking it consisted of 23 separate processes. But because of the PCF you now have a realistic reference that should help you begin to realize that process mapping/modeling.
Primary Variable #2: The Level of Detail Required
In general, the purpose of most process mapping/modeling projects is to support business process improvement. And since most business processes involve heavy use of computer software you should expect that process modeling/mapping will need to be done at the lowest level of detail. That means you will have to be equally specific and precise down to the task/step level of detail. In other words, it’s inadequate to merely write a data entry task as, “Update the Job Requisition record.” You have to drill down even further. You will have to specify the specific fields within a job requisition that require data entry. And usually you’ll need to specify the data type and range of acceptable values that can or should be entered in each field.
Why? Because most business process problems don’t happen because someone performed a step out of sequence. Rather, the majority of problems occur at the step level where the performer fails to properly (thoroughly/completely/accurately/precisely) perform the step. That’s because most of the actual “work” or effort in a business process consists of some type of user interaction with software.
Primary Variable #3: The Workflow Diagramming Notation to be Used
Anyone can draw a flowchart. But there’s a big difference between a flowchart created by the average knowledge worker or manager (i.e. “Citizen Diagrammer”) and a notational-standard business process diagram created by a business process modeling practitioner. That’s because business process modeling practitioners typically create business process diagrams that comply with diagramming standards such as the Business Process Model and Notation (BPMN) or the Event Process Chain (EPC) standard. And the reason for using a standard notation is because a pre-defined diagramming notation can consistently accommodate every structural element of a business process.
If diagramming is left to citizen diagrammers who aren’t required to follow any notational standard then it’s reasonable to assume that it might take less time to create a diagram using the diagrammer’s “personal” notation. But that comes with the risk of loss of quality and value. The four primary quality attributes of thoroughness, completeness, accuracy, and precision of information are likely compromised. One of the benefits of using a formal, structured notation like BPMN or EPC is that they provide a set of diagramming principles and elements that help ensure all categorical elements of a process are included in the diagram.
But the cost of using a standard notation – compared to a personal notation – is time. Structure imposes discipline. But, as experience has taught me, once a business process modeler attains expert-level skill with a standard notation, work speed increases. The end result? A higher level of thoroughness, completeness, accuracy, and precision than anything a citizen diagrammer can produce.
The Other Variables
There are several other variable factors to consider when estimating the work effort and duration involved in business process mapping and modeling. The following list should give you a general idea of the wide range of factors:
The Experiential Estimation Method
Prior experience is the only estimation factor in this method. If the organization has no substantial prior formal experience to reference, then the only solution is to start gaining experience.
Start small. For example, start with one of your organization’s purchasing department’s processes. Narrow it down to the sub-processes involved in creating and approving purchase requisitions and purchase orders. Using the APQC’s Process Classification Framework (PCF) as a model, those sub-processes include:
Start with combining the first two sub-processes, Process/Review Purchase Requisitions and Approve Requisitions. In general, this work involves the creation of a purchase requisition and the approval of that purchase requisition. Be careful not to include the subsequent process of creating and submitting a Purchase Order to a supplier vender.
Assign one person to perform the work of creating one or more low-level process diagrams. Spend time planning and organizing that effort. The goal of that planning and organization is to define a structured approach to process mapping that enables a consistent, repeatable method for measuring the work effort. In other words, create a reliable measurement formula.
Emphasize the goal of quality. Don’t put any pressure on the process mapper to speed up the work at the risk of quality. The pressure should only be to stick to the process mapping work framework you defined prior to starting the process mapping effort. What you’re trying to do is measure how much time it takes to achieve the process mapping quality goals. The only thing you have to manage from a “command-and-control perspective is to make sure the process mapper isn’t distracted from the effort. The discipline in staying focused on the effort is your responsibility to manage. Remove obstacles and distractions, and keep the process mapper focused on completing the work.
When the work is done, you’ll have some experience to work with. Every organization has its own set of variables, some more prominent than others. Then you can decide how much time and money it might take to do more process mapping.
Obviously, this means you must be willing to make an initial outlay toward this first process mapping effort. As an example, in my experience mapping the PR process can involve up to 80 hours of total effort across a 4-business week duration. Using an average billing rate of $100 an hour, your total investment would be $8,000. Would you be willing to spend $8,000 In other words, are you willing to spend $8000 to find out how much time it might take to adequately diagram a common type of process?
Extend the further to the entire range of processes involved in the overall process of “Procure Materials and Services.” Using the PCF, there are 22 discrete sub-processes involved. At approximately 40 effort hours per process, that’s 880 hours of work. At $100/hour it adds up to $88,000 to completely document the purchasing department.
That’s the first time you do any process mapping. In the future you might be able to use less expensive process mappers. They would be the people who the PM consultant trained wheile he was doing the Purchasing process mapping.
Using an internal fully-loaded resource cost of $50/hr, you cut the cost by half. Subsequent equivalent process mapping projects then might cost $44,000 per major function. There are four major functions in the “Deliver Physical Products” super-process. Thus it might cost you between $176,000 and $352,000 to fully document all the processes in delivering physical products.
The most effective method of estimating is based on measuring your history of performing and managing the work. In other words, your first few process mapping/modeling projects will be hard to estimate. You’ll have to gain some carefully-measured experience so you can identify the extent and stability of the variables. With experience you’ll start to realize what those variables are and the extent of each variable.
I’ve been doing this kind of work for more than 20 years. Over that time, I’ve only seen one mathematically oriented estimating method. But that didn’t include any information about the effectiveness of the method. All the rest of the literature on the subject generally addresses the time consumed during so-called business process “discovery” meetings. These meetings are often labeled as group interviews, brainstorming, or Joint Application Development (JAD) session meetings. And it’s implied that these types of meetings are all that’s needed to effectively and efficiently gather, clarify, and confirm enough information to quickly create useful workflow diagrams.
Mapping vs Modeling
By the way, most organizations I’m aware of don’t make a distinction between business process mapping and business process modeling. To them, the terms are synonymous and both only refer to the work of creating business process workflow diagrams. Even within the community of business process mapping/modeling practitioners, there is little agreement about the definitions. Thus, one of the first factors to deal with is to define the difference between mapping and modeling.
In my vocabulary, business process mapping refers to the work of creating business process workflow diagrams. No other documentation is included in the scope of work. The work of business process modeling extends the documentation beyond workflow diagrams. While high-quality, detailed workflow diagrams can illustrate and communicate a lot of process information, other types of diagrams and documents provide additional, needed information and perspectives. Those needs and perspectives are determined by both the purpose of business process documentation and the audience and beneficiaries of the information. Bottom line, there is more work involved in process modeling than there is in process mapping.
Three Primary Variables
Since workflow diagramming exists in both process mapping and process modeling, we’ll start with the first three primary factors/variables related to the work. Those factors are (1.) the scope of processes to document, (2.) the level of detail required, (3.) the workflow diagramming notation to be used.
Primary Variable #1: The Scope of Processes to Document
A valuable tool and information to use in defining the scope of process mapping/modeling is APQC’s Process Classification Framework (PCF). As the name implies, a PCF is a categorized, multi-level outline of business processes commonly found in nearly every type of business enterprise. Using 13 different, high-level process classes it shows up to five sub-process levels for each.
For example, let’s say your project involves process modeling in support of the slection, configuration, and implementation of a new Applicant Tracking System (ATS) for the human resources department. Using the PCF as a guideline, ATS processes fall under the PCF’s “7.2 Recruit, source, and select employees” sub-process. That sub-process is a second-level process of the higher level, “7.0 Develop and Manage Human Capital,” process which is one of the 13 high-level processes of the PCF.
There are five separate sub-processes under “7.2 Recruit, source, and select employees”:
- 7.2.1 Manage employee requisitions
- 7.2.2 Recruit/Source candidates
- 7.2.3 Screen and select candidates
- 7.2.4 Manage new hire/re-hire
- 7.2.5 Manage applicant information
Each of those have between three and seven sub-processes under them. Specifically, in total, there are 23 distinct sub-process that could potentially be modeled. You have to admit, when you first saw the “7.2 Recruit, source, and select employees” high-level process name you probably weren’t thinking it consisted of 23 separate processes. But because of the PCF you now have a realistic reference that should help you begin to realize that process mapping/modeling.
Primary Variable #2: The Level of Detail Required
In general, the purpose of most process mapping/modeling projects is to support business process improvement. And since most business processes involve heavy use of computer software you should expect that process modeling/mapping will need to be done at the lowest level of detail. That means you will have to be equally specific and precise down to the task/step level of detail. In other words, it’s inadequate to merely write a data entry task as, “Update the Job Requisition record.” You have to drill down even further. You will have to specify the specific fields within a job requisition that require data entry. And usually you’ll need to specify the data type and range of acceptable values that can or should be entered in each field.
Why? Because most business process problems don’t happen because someone performed a step out of sequence. Rather, the majority of problems occur at the step level where the performer fails to properly (thoroughly/completely/accurately/precisely) perform the step. That’s because most of the actual “work” or effort in a business process consists of some type of user interaction with software.
Primary Variable #3: The Workflow Diagramming Notation to be Used
Anyone can draw a flowchart. But there’s a big difference between a flowchart created by the average knowledge worker or manager (i.e. “Citizen Diagrammer”) and a notational-standard business process diagram created by a business process modeling practitioner. That’s because business process modeling practitioners typically create business process diagrams that comply with diagramming standards such as the Business Process Model and Notation (BPMN) or the Event Process Chain (EPC) standard. And the reason for using a standard notation is because a pre-defined diagramming notation can consistently accommodate every structural element of a business process.
If diagramming is left to citizen diagrammers who aren’t required to follow any notational standard then it’s reasonable to assume that it might take less time to create a diagram using the diagrammer’s “personal” notation. But that comes with the risk of loss of quality and value. The four primary quality attributes of thoroughness, completeness, accuracy, and precision of information are likely compromised. One of the benefits of using a formal, structured notation like BPMN or EPC is that they provide a set of diagramming principles and elements that help ensure all categorical elements of a process are included in the diagram.
But the cost of using a standard notation – compared to a personal notation – is time. Structure imposes discipline. But, as experience has taught me, once a business process modeler attains expert-level skill with a standard notation, work speed increases. The end result? A higher level of thoroughness, completeness, accuracy, and precision than anything a citizen diagrammer can produce.
The Other Variables
There are several other variable factors to consider when estimating the work effort and duration involved in business process mapping and modeling. The following list should give you a general idea of the wide range of factors:
- The true knowledge and capabilities of business process subject matter experts (SMEs) and other process stakeholders – including executives (the so-called “process owners”), process managers, process performers, process suppliers, process customers/beneficiaries, or anyone else who directly or indirectly impacts, or is impacted by, a process
- Their knowledge of the process in terms of thoroughness (range and depth), completeness, accuracy, and precision
- Their ability to effectively communicate that knowledge
- The availability of the SMEs and other process stakeholders
- The complexities of a process
- The number of discrete task steps in a process
- The extent of workflow and data object state/status changes
- The number and complexity of decision tasks in a process
- The resulting workflow path divergencies based on the results of decision tasks
- The extent of interruption and error handling tasks
- The number of starting, intermediate, and ending events in a process
- The number of process participants
- The availability of existing process diagrams and documentation (used by a Business Process Analyst to create the first, “scrutiny draft” of a process map)
- The quality of the current state of a process (how efficiently and effectively it accomplishes its performance goals today)
- Process mapping efforts are sometimes forced to be delayed because process managers and other SMEs need stop and go to fix process problems they were unaware of before process mapping began
- Agreement among process stakeholders about the details of a process
- It’s not unusual for process owners, managers, performers, and SMEs to argue about:
- How a process is designed to work
- How they believe a process is currently performed
- How a process is actually performed
- This is what I refer to as The Process Quality Disconnect Triad
- The tools used to create, store, control, publish and distribute business process maps and additional supporting documentation
- The knowledge, skills, and experience of the people (e.g. business process analysts) assigned to the work of process discovery, analysis, diagramming and documentation
- The time it takes for the business process analysts to advance to the highest level of Bloom’s Taxonomy
The Experiential Estimation Method
Prior experience is the only estimation factor in this method. If the organization has no substantial prior formal experience to reference, then the only solution is to start gaining experience.
Start small. For example, start with one of your organization’s purchasing department’s processes. Narrow it down to the sub-processes involved in creating and approving purchase requisitions and purchase orders. Using the APQC’s Process Classification Framework (PCF) as a model, those sub-processes include:
- 4.2.4.1 Process/Review Purchase Requisitions
- 4.2.4.2 Approve Requisitions
- 4.2.4.3 Solicit/Track Vendor quotes
- 4.2.4.4 Create/Distribute Purchase Orders
Start with combining the first two sub-processes, Process/Review Purchase Requisitions and Approve Requisitions. In general, this work involves the creation of a purchase requisition and the approval of that purchase requisition. Be careful not to include the subsequent process of creating and submitting a Purchase Order to a supplier vender.
Assign one person to perform the work of creating one or more low-level process diagrams. Spend time planning and organizing that effort. The goal of that planning and organization is to define a structured approach to process mapping that enables a consistent, repeatable method for measuring the work effort. In other words, create a reliable measurement formula.
Emphasize the goal of quality. Don’t put any pressure on the process mapper to speed up the work at the risk of quality. The pressure should only be to stick to the process mapping work framework you defined prior to starting the process mapping effort. What you’re trying to do is measure how much time it takes to achieve the process mapping quality goals. The only thing you have to manage from a “command-and-control perspective is to make sure the process mapper isn’t distracted from the effort. The discipline in staying focused on the effort is your responsibility to manage. Remove obstacles and distractions, and keep the process mapper focused on completing the work.
When the work is done, you’ll have some experience to work with. Every organization has its own set of variables, some more prominent than others. Then you can decide how much time and money it might take to do more process mapping.
Obviously, this means you must be willing to make an initial outlay toward this first process mapping effort. As an example, in my experience mapping the PR process can involve up to 80 hours of total effort across a 4-business week duration. Using an average billing rate of $100 an hour, your total investment would be $8,000. Would you be willing to spend $8,000 In other words, are you willing to spend $8000 to find out how much time it might take to adequately diagram a common type of process?
Extend the further to the entire range of processes involved in the overall process of “Procure Materials and Services.” Using the PCF, there are 22 discrete sub-processes involved. At approximately 40 effort hours per process, that’s 880 hours of work. At $100/hour it adds up to $88,000 to completely document the purchasing department.
That’s the first time you do any process mapping. In the future you might be able to use less expensive process mappers. They would be the people who the PM consultant trained wheile he was doing the Purchasing process mapping.
Using an internal fully-loaded resource cost of $50/hr, you cut the cost by half. Subsequent equivalent process mapping projects then might cost $44,000 per major function. There are four major functions in the “Deliver Physical Products” super-process. Thus it might cost you between $176,000 and $352,000 to fully document all the processes in delivering physical products.